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1 Introduction 

Embedded  systems  and  networks  are  becoming  increasingly  prevalent  in  critical  sectors,  such  as  medical 
and  defense  sectors.  Therefore,  malicious  or  accidental  failures  in  embedded  systems  can  have  dire  conse- 
quences. Hence,  the  integrity  of  embedded  software  infrastructures,  such  as  configuration  and  code,  is  of 
paramount  importance.  The  autonomous  nature  of  embedded  systems  also  poses  new  challenges  in  the  con- 
text of  system  integrity.  Since  embedded  systems  are  reactive,  unexpected  or  malicious  environment  events 
or  can  cause  failures,  which  can  have  dire  consequences  in  critical  sectors.  Embedded  systems  and  networks 
also  often  have  to  operate  autonomously  in  a dynamic  environment.  Therefore,  an  embedded  system  has  to 
adapt  its  behavior  to  the  change  in  environment  or  the  overall  goal.  Unauthorized  or  unverified  updates  to 
the  infrastructure  of  an  embedded  system  can  also  compromise  its  integrity. 

In  recent  years,  there  have  been  significant  advances  in  the  area  of  software  security.  There  have  been 
various  techniques  developed  in  the  context  of  software  security,  such  as  automated  signature  generation, 
vulnerability  assessment,  and  detecting  malicious  behavior.  However,  all  these  techniques  are  not  directly 
applicable  in  the  context  of  embedded  systems  because  of  following  reasons: 

• Dynamic  and  configurable  environment:  Embedded  systems  are  generally  deployed  in  environments 
that  are  highly  dynamic  and  configurable.  For  example,  the  environment  of  an  embedded  system 
deployed  in  a battlefield  is  extremely  dynamic. 

• Changing  functional  requirements:  Functional  requirements  of  an  embedded  system  change  over 
time.  Functional  requirements  of  an  embedded  system  deployed  in  a battleship  change  with  mission 
of  the  operation. 

• Interconnected  network  of  components:  Frequently  an  embedded  system  is  a complex  network  of 
components.  Therefore,  a malicious  or  accidental  fault  in  a component  can  lead  to  a complex  cascade 
of  events  in  the  network. 

• Recovery  is  paramount:  Generally,  techniques  developed  in  the  realm  of  software  security  focus  on 
detection  and  prevention.  Embedded  systems  are  frequently  deployed  in  mission  critical  applications 
where  consequences  of  failures  can  be  dire.  Therefore,  recovery  from  failures  is  extremely  important 
in  the  context  of  embedded  systems. 


2 Promising  Research  Directions 

Extending  existing  techniques  in  software  security  to  handle  the  four  abovementioned  characteristics  of 
embedded  systems  is  an  important  research  direction.  I will  provide  details  of  two  such  research  directions. 
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• Vulnerability  assessment  and  prevention  in  presence  of  a dynamic  environment:  Existing  techniques 
for  vulnerability  assessment  have  been  developed  for  systems  (such  as  servers)  whose  environments 
are  relatively  static.  Extending  dynamic  and  static  analysis  techniques  for  vulnerability  assessment 
and  prevention  for  systems  with  dynamic  environments  is  a very  interesting  research  direction.  I envi- 
sion that  existing  techniques  will  have  to  be  extended  to  incorporate  specification  of  the  environment. 
In  this  context,  an  interesting  research  direction  would  be  to  generate  vulnerability  signatures  [2,  6] 
for  systems  with  dynamic  environments.  I envision  the  signatures  in  this  case  will  be  parametrized  by 
a specification  of  the  environment,  i.e.,  signatures  will  only  be  valid  if  certain  environment  conditions 
are  satisfied. 

• Recovery  from  malicious  or  accidental  faults:  As  mentioned  before  an  embedded  system  is  a complex 
network  of  components.  Therefore,  a fault  in  a component  can  create  a ripple  of  events  throughout 
the  network.  This  makes  recovery  for  embedded  systems  extremely  challenging.  A causality  graph 
for  an  embedded  system  is  a graph  where  the  nodes  are  events  and  edges  are  the  causality  between 
events  (e  — > e'  means  that  event  e can  cause  event  er).  Techniques  for  discovering  a causality  graph 
of  an  embedded  is  essentially  for  recovering  from  faults.  Essentially  the  effects  of  a fault  can  be 
determined  from  examining  the  causality  graph.  Techniques  for  constructing  attack  graphs  [1,5]  and 
alert  correlation  [3,  4] 
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Software  Security 

• Vulnerability  Assessment 

-Analysis  tools  for  discovering  vulnerabilities  in 
source  code  and  binaries 

• Automated  Signature  Generation 

- Generating  signatures  that  filter  our  malicious 
inputs 

• Malicious  Code  Detection 

- Detecting  whether  a binary  has  malicious 
behavior 


Embedded  Systems 

• Increasingly  used  in  critical  sectors 

- Defense,  medical,  power,  ... 

• Malicious  and  accidental  failures  can  have 
dire  consequences 

• Embedded  systems  are  not  “all  hardware” 

- They  have  software  too© 

• Autonomous  nature 


Dynamic  and  Configurable 
Environment 

• Embedded  systems  are  highly 
configurable 

- They  have  to  work  in  many  different  scenarios 

• Environment  is  highly  dynamic 

- Think  about  embedded  systems  in  a 
battlefield 

- Embedded  system  in  a vehicle 


Changing  Functional  Requirements 

• Functional  requirements  of  embedded 
systems  change  over  time 

• Embedded  system  deployed  in  a 
battlefield 

- Functional  requirements  change  with  mission 


Interconnected  Network  of 
Components 

• Embedded  system  are  of  a complex 
network  of  components 

• Components  might  be  hardware  or 
software 

• Source  code  might  be  available  for  some 
components 

• COTS  components  (only  binary  available) 

• Failure  can  create  cascading  events 


Recovery  is  Paramount 

• Embedded  systems  used  in  critical 
applications 

• In  some  cases  recovery  is  paramount 

• Recovery  complicated  by  complex 
interaction  of  events 

- Failure  can  cause  a complex  cascade  of 
events 


Three  Software  Security  Projects 

• Automated  generation  of  vulnerability 
signatures 

• Retrofitting  legacy  code 

• Static  analysis  of  binaries 
- Malware  Detection 
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Adversary 


mm  zau>  mm.  set 


■ « ■ * 4 ♦ ♦ 4 ♦ ♦ 4 ♦ ♦ 4 * 4 4 4 » 


Victim 


Many,  perhaps  infinite, 
Polymorphic  variants 


Goals  for  Automatic  Signature 
Generation 

• Create  signature  that  matches  exploits 

• Reason  about  signature  accuracy 

—Does  it  match  legitimate  traff  ic  (false  +)? 

—Does  it  miss  exploits  (false  -)? 


Our  Contribution: 

A Language-Centric  Approach 

Focus  on  the 

language  of  the  vulnerability 

4 Reason  about  signature  via 
language 

4 Language  captures  all  exploits 

New  methods  for 
Automatic  vulnerability 
signature  creation 

^Opens  doors  to  PL  techniques^ 


Language  of  a Particular 
Vulnerability 

• A vulnerability  is  defined  by: 

1 . What  - The  Vulnerability  Condition: 
Necessary  conditions  to  violate  safety 

2.  Where  - The  Vulnerability  Point: 

Location  vulnerability  condition  first  satisfied 

The  Vulnerability  Language  is  all  input 
strings  reaching  the  vulnerability  point 
meeting  the  vulnerability  condition. 
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HTTP-like  Running  Example 

1 . int  check_http(char  input[9]) 

2-  { 

3.  if(strcmp(input,  “get”, 3)  !=  0 || 

4.  strcmp(input,  “head”, 4)  !=  0)  return  -1 ; 

5.  if(input[4]  !=  7‘)  return  -1 ; 

6.  int  I = 5; 

7.  while(input[l]  !=  ‘\n‘){  I++; } 

8.  input[l]  = 0; 

9.  return  i;  Our  implementation 

10. }  is  on  binaries 


Example  Input:  get_/aaaa\n 

1 . int  check_http(char  input[9]) 


2-  { 

3. 

if(strcmp(input,  “get”, 3)  != 

= 0 || 

4. 

strcmp(input,  “head”, 4) 

i !=  0)  return  -1; 

5. 

if(input[4]  !=  7‘)  return  -1 ; 

6. 

int  1 = 5; 

7. 

while(input[l]  !=  ‘\n‘){  I++; } 

8. 

input[l]  = 0;  - — — ' 

Vulnerability  Point 

9. 

return  1; 

10.} 
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Example  Input:  get_/aaaa\n 

1 . int  check_http(char  input[9]) 


2-  { 

3. 

if(strcmp(input,  “get”, 3)  != 

0 | 

4. 

strcmp(input,  “head”, 4) 

I != 

5. 

if(input[4]  !=  7‘)  return  -1 ; 

6. 

int  1 = 5; 

7. 

while(input[l]  !=  ‘\n‘){  I++; } 

8. 

input[l]  = 0;  - — 

9. 

return  1; 

10.} 

i 

Vulnerability 
Condition:  I >=  9 


Retrofitting  legacy  code 

Need  systematic  techniques  to 
retrofit  legacy  code  for  security 


Legacy 
code 

INSECURE 


Retrofitted 

code 

SECURE 


Retrofitting  legacy  code 

Need  systematic  techniques  to 
retrofit  legacy  code  for  security 

• Enforcing  type  safety 

- CCured  [Necula  etaL  J02] 

• Partitioning  for  privilege  separation 

— PrivT Tans  [Brumley  and  Song,  ’04] 

• Enforcing  authorization  policies 


Enforcing  authorization  policies 


Resource  user 

Operation  request^-  ^Response 

Resource  manager 


Allowed?  4/  T'YES/NO 
< Alice,  /etc/passwd,  File  Read} 


Retrofitting  for  authorization 

• Mandatory  access  control  for  Linux 

- Linux  Security  Modules  [Wright efa/,  02] 

- SELinux  [Loscocco  and  Smalley, ’01] 

• Painstaking,  manual  procedure 

-Trusted  X,  Compartmented-mode  workstation, 

XI  1/SELinux  [Epstein  et  a/./90][Berger  et a/./90][Kilpatnck  et a/., ’03] 

• Java  Virtual  Machine/SELinux  [Fletcher, ‘06] 

• IBM  Websphere/SELinux  [Hocking  et  ai;  06] 
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Problems 

• Time-consuming 

- XI  1/SELinux  ~ 2 years  [Kilpatrick  et  al..,  ‘03] 

- Linux  Security  Modules  ~ 2 years  [wnght etai.,  02] 

• Error-prone  [Zhang  et  al.,  ‘02][Jaeger  et  al.,  ‘04] 

-Violation  of  complete  mediation 

- Time-of-check  to  Time-of-use  bugs 


Our  approach 

Reduces  manual  el 

• Retrofitting  takes  just  a few  hours 

-Automatic  analysis:  ~ minutes 

- Interpreting  results:  ~ hours 

Reduces  errors 

• Basis  to  prove  security  of  retrofitted  code 
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Malspec:  Self-Propagation  by  Email 


Malspec:  Self-Propagation  by  Email 


Malspecs  Benefits 


S Symbolic  variables 

s Constraint-based 
execution  order 

s Independent  of 
obfuscation 
artifacts 


Expressive  to  describe  even  obfuscated  behavior. 


Malspec  Detection  Strategies 

? 

* Static  analvsis 

X:=socket(l| 

connect(X]J.  J.S:=process_name() 

gliliilliigllillgliiiliSlgllgigigiglp 

m ...  ...  « 

m 

m- 

•.Dynamic  analysis....; 

send(X,“EHLO”X  Tz:=open(S) 

send(X,“DATA”J/ 

'yftC  Y:=read(Z) 

send(X,T)  Y 

• Host-based  IDS 

StringEqual(T,Base64(  Y ) ) J/ 

• Inline  Reference 

Monitors 

Malspecs  are  independent  of  detection  methc  * 
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avio 


Binary 

File 


X:=SQcket(j 

c;;< 

connect(X) 

< 

send(X,“EHLO”* 

< 

send(X,“DATA”! 
send(X,T)  ^ 

StringEquai(T,Base64('i)]k 


S:=process_name() 

Z:=open(S) 


Malware 

Detector 


Goal:  Find  a program  path  that  matches  the  malspec. 


Find  A Malicious  Program  Path 


\ k 

\ p 

— »TT1 

□ J 


X:=socket(^ 

o 

connect(Xw 

Y 

WS:=process_name(} 

send(X,“  E HLO”U/ 

T Z:=open(S) 

P 

send(X,“  DATA’ 

/ 

• Y:=read(Z) 

send(X,T)  J 

Interprocedural 
Control- Row  Graph 


Stable  Environment  Assumption 

• All  the  above  mentioned  work  assumes  a 
“nearly”  stable  environment 

• Example:  web  server 

- Is  configurable,  but  the  environment  is  not  that  rich 

- Environment  is  not  too  dynamic 

- Not  rich  interaction  with  other  components 

• Incorporating  “dynamic  environments”  into  the 
techniques  described  before  is  a challenge 


Vulnerability  Assessment  in 
Presence  of  a Dynamic 
Environment 

• Dynamic  and  static  analysis  techniques 
assume  a relatively  stable  environment 

• Parameterized  static  analysis 

- Parameterize  static  analysis  with  environment 
assumptions 

- Similar  to  assume-guarantee  reasoning  in 
model  checking 

• Parameterized  vulnerability  signatures 


Recovery  from  Failures 

• A failure  (malicious  or  benign)  can  cause  a 
complex  cascade  of  events 

• Need  to  understand  the  complex  cascade 
of  events  caused  by  a failure 

• Need  to  analyze  the  complex  network  in 
components  in  totality 

- Scalability 

- Compositional  analysis 


Questions 

• My  web  page 

- http://www.cs.wisc.edu/~jha 


